SOLR-17316: make SolrJ response objects work with non-binary ResponseParsers - #4640

The SolrJ response classes assume the Java types the binary parser produces, so
reading a response parsed by a non-binary parser (e.g. the JSON map parser) threw
ClassCastException: JSON yields raw Map/List where the code expects
NamedList/SolrDocumentList, and Long where it casts to Integer.

- ResponseNormalizer converts a parsed response into the canonical shape (nested
  objects -> NamedList/SimpleOrderedMap, a {numFound,docs} object ->
  SolrDocumentList); it is a no-op for already-canonical binary/XML responses.
- ResponseParser.producesCanonicalForm() gates it; JsonMapResponseParser returns
  false. HttpSolrClient normalizes at the shared response boundary, covering both
  the JDK and Jetty transports while binary/XML pay nothing.
- Remaining numeric reads that cast to Integer/Float are widened via Number
  (grouping, interval and pivot facet counts, spellcheck, analysis token offsets,
  Luke, schema version).

Tests cover the normalizer, cross-format parity (binary/XML/json-map), each
affected section, and an end-to-end HTTP query with the JSON parser on both
transports.

… map parser

Extends the randomization SOLR-15070 introduced in that test — javabin or xml — to
pick among three parsers, so the JSON map parser goes through the same suggester
assertions as the other two.

It is a regression test for this PR rather than added coverage: on the commit
before the normalizer, forcing that parser in fails all three of the test's
methods with

  ClassCastException: class java.util.LinkedHashMap cannot be cast to class
  org.apache.solr.common.util.NamedList

and with the conversion in place they pass. Mutation-checked — removing the
conversion from JsonMapResponseParser#processCanonicalResponse brings the
ClassCastException back under -Ptests.iters=10.

The test fed the JSON parser a literal whose facet_fields was written in json.nl=map
form, which JsonMapResponseParser never requests, so the input shape does not occur on
a live request — running the response classes end-to-end over a real server surfaced
that same section failing as an array. Two of its three methods also asserted existing
javabin and xml behaviour rather than anything this change introduces.

Coverage of the numeric widening in QueryResponse is kept by
QueryResponseSectionParityTest, and of a real request by
QueryResponseJsonParserIntegrationTest.

…and have the JSON map parser ask for json.nl=map

JsonMapResponseParser could not read the response it was getting. Under the default
json.nl=flat a NamedList is written as an array of alternating names and values, so
facet_fields arrived as a List where the response classes expect a NamedList, and the
structure cannot be recovered after the fact. The style had to be set by hand on every
request, which is not something a caller should have to know per parser.

ResponseParser#getRequestParams supplies params alongside wt. Anything the request set
explicitly wins, so this only provides defaults. Applied in
HttpSolrClient#initializeSolrParams, which every HTTP client routes through.

QueryResponseJsonParserIntegrationTest no longer sets json.nl itself, which is what the
change is for, and asserts that an explicit value survives.

JSON has no document type, so the JSON writer emits nested documents as a
_childDocuments_ field holding a list of maps. The binary and XML parsers hand them back
as child documents; this one left them as a plain field, so SolrDocument#hasChildDocuments
was false and the children were unreachable through the documented accessors.

Nesting is recursive, so grandchildren are covered too.

facet_queries, a range facet's counts and a pivot's query counts were cast to
NamedList<Integer> and iterated as Integer entries, so a response whose numbers arrive as
Long threw ClassCastException. Same defect as the accessors already widened here, in three
places the earlier commits did not reach; the values are still narrowed to int, so
nothing about the public types changes.

SolrExampleTests has a subclass per parser and JSON was missing, so the whole 42-test
suite now runs against JsonMapResponseParser. That is what found the three defects fixed
in the preceding commits; on the commit before them it fails seven ways.

Nine assertions in SolrExampleTests pinned the boxed type of a number rather than its
value -- (Integer) getFieldValue(..), assertEquals(1.0f, ..), RangeFacet<Float, Float> --
and are relaxed to Number where the value is the point. Nothing is ignored: 42 of 42 pass,
and the binary, XML, CBOR and HTTP/2 subclasses are unaffected.

…ments

The only textual conflict was two imports in HttpSolrClient: SOLR-18351 removed
ContentStream from this file, SOLR-17316 added SolrParams. Compilation then
failed on ResponseNormalizerTest, because SOLR-18353 removed
SolrDocument.getChildDocumentCount() -- switched to getChildDocuments().size().